home *** CD-ROM | disk | FTP | other *** search
/ Nebula 2 / Nebula Two.iso / SourceCode / MiscKit1.7.1 / MiscKitArchive.mbox / mbox / 000087_yackd@alaska.et.byu.edu_Mon Nov 1 00:50 MST 1993.msg < prev    next >
Internet Message Format  |  1994-10-30  |  3KB
  1. Received: from yvax.byu.edu by maine.et.byu.edu; Mon, 1 Nov 93 00:50:36 -0700
  2. Return-Path: <yackd@alaska.et.byu.edu>
  3. Received: from DIRECTORY-DAEMON by yvax.byu.edu (PMDF V4.2-13 #4169) id
  4.  <01H4S6BGBOB48WZCLG@yvax.byu.edu>; Mon, 1 Nov 1993 00:48:33 MST
  5. Received: from alaska.et.byu.edu by yvax.byu.edu (PMDF V4.2-13 #4169) id
  6.  <01H4S6BD62Z48Y5UO9@yvax.byu.edu>; Mon, 1 Nov 1993 00:48:29 MST
  7. Received: by alaska.et.byu.edu; Mon, 1 Nov 93 00:50:21 -0700
  8. Date: Mon, 01 Nov 1993 00:50:21 -0700
  9. From: yackd@alaska.et.byu.edu (Don Yacktman)
  10. Subject: Re:  release of MiscKit 1.0 miscellanea
  11. To: Don_Yacktman@byu.edu, kane@sonata.cc.purdue.edu
  12. Message-Id: <9311010750.AA18343@alaska.et.byu.edu>
  13. Content-Transfer-Encoding: 7BIT
  14. Status: RO
  15.  
  16. Sorry I've been slow to get anything out.  I have been really
  17. swamped at this end.  Really bad.  Basically, the person I am
  18. doing some consulting stuff for just hit his deadline for a
  19. presentation and so I've spent the week busting my rear to
  20. squeeze in as many extra features as I can.  I think I did
  21. OK at that.  :-)  However, that means that the MiscKit had
  22. to take a breather.  Hopefully I can get the rest of this
  23. wrapped up.  I really had a bunch of things I wanted to fix
  24. for 1.0, and therefore think a release delayed until a little
  25. after the clamor of 3.2 might be the easiest.  (But you are
  26. right in that it would be great to release _before_ then.  I
  27. just doubt that I can prepare something I'd be pleased with
  28. in time to do that.)  Well, as usual, I'll have to play it
  29. by ear.
  30.  
  31. As to _where_ I will release it, the orst and sonata sites would
  32. be wonderful.  I had planned on orst at least, and if you can
  33. clear space on sonata for it, even better.  (When I do the
  34. release I will place it on byu and orst, and let you copy it to
  35. sonata yourself, so you can be sure that noone else tries to
  36. slip a file in there between when you would clear it and I would
  37. get the message...)  I have no problem with it turning up on
  38. every archive in the world...and I'd certainly want it on an
  39. archive (at least one) that archie knows about.
  40.  
  41. I'll keep using ftp.byu.edu for minor revisions and working
  42. copies, but all major releases and any minor release with
  43. significant changes or bug fixes will definitely go to the
  44. archives.  You know, one thing we never decided is how to choose
  45. whether to bump up a major or minor revision number...hmmm...
  46. it might be good to state some sort of policy in the charter, don't you think?
  47. What might you suggest?  If I do a major number each time I
  48. add objects/resources, it'll go up too quickly, but if I
  49. don't then how do I distinguish between bug fix releases and
  50. new functionality?  Maybe something like x.y.z for the number
  51. where z is only bug fixes, y adds functionality (new resources)
  52. and x is >10 new resources or something like that.  Opinions?
  53.  
  54. Well, I've got work to do...
  55.  
  56. Later,
  57. -don